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ABSTRACT 


lEDs continue to harass, maim, and kill innocent men, women, and children, as well as 
numerous coalition and U.S. forces. Currently, over 50% of U.S. casualties are caused by 
lEDs. To combat this terror, the U.S. government has employed significant resources 
across a diverse range of dedicated researchers and testers. However, in working so 
diligently to test the separate components of an lED defeat system, opportunities are 
missed to effectively utilize the information available across the test enterprise and in the 
theater of operations. The analyses conducted by Eieutenant Robert Gill and Major Rick 
EaViolette revealed potential areas of improvement in the business processes at the 
JIEDDO Test Board (JTB). The focus of this thesis is to use the results produced by the 
research conducted by Gill and EaViolette to develop requirements to build a set of 
collaboration tools and associated processes that will support the needs of the end users in 
theater. The objective of this analysis is to identify requirements that will support the 
development of web-based tools and describe how the tools will provide input to enhance 
the JIEDDO test process system. 
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I. 


INTRODUCTION 


The JIEDDO Test Board (JTB) Enterprise is comprised of many organizations 
that conduct testing and research on Improvised Explosive Devices (lEDs). This large 
organization holds a data warehouse of information that must be managed to meet the 
daily requirements for information across the organization which spans several continents 
from the U.S. to supporting troops in theater and that information must be distributed to 
the customers throughout the world. The method JIEDDO employs to process requests 
for information (REI) is described in Gill, 2011; that research illustrated the complexity 
of the JIEDDO organization and the process involved in using the established REI 
procedure to obtain information. The organization of JIEDDO can be difficult to 
understand. The term JIEDDO refers to the large organization that encompasses many 
smaller entities that support the larger organization. The JTB oversees the testing and 
evaluation in JIEDDO, but the JTB is subordinate to JIEDDO. The JTB is a group of 20 
to 30 personnel who are mostly located in the Washington D.C. area. The JTB enterprise 
sponsors test centers, test laboratories, and research activities to perform the work of the 
JTB. Thus the JTB and these paid activities comprise the JTB enterprise. EaViolette 
(2011) describes how the holders of information in the organization share information 
and how they decide with whom they will share information. With this foundational 
understanding of organizational issues as well as the thought processes employed by 
members of the JTB enterprise, the enterprise can be examined as a complete system. 
Analysis of the system as a whole can identify potential ways to improve the efficiency 
of the system. 

A. IMPROVISED EXPLOSIVE DEVICES (lED) 

It is essential to understand that the objective of information sharing associated 
with lED research is to prevent the loss of life. Collaboration amongst the researchers, 
managers and soldiers in the field must have a sense of urgency. In addition to this sense 
of urgency participants must also have an awareness of what information is critical and 
who would benefit from receiving the information. The soldier in the field has many 
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pieces of information he must master as well as manage to ensure he and his teammates 
can perform their missions with minimal risk from lEDs. The end user of the information 
may not require much knowledge of how his actions will mitigate risk, but he or she 
needs to have the most current information that will ensure their actions have capitalized 
on the considerable research conducted by JIEDDO. Counter-IED (C-IED) researchers 
working in the various test environments have a greater need for detailed information to 
apply the information to the design of C-IEDs and share the detailed information amongst 
his or her colleagues. Data produced in the test environment must be captured and stored 
in a manner that can be efficiently inventoried, categorized, searched, and shared by 
members throughout the organization. Managers in the JTB organization have the most 
critical requirement for understanding how information is used at every level. Managers 
must ensure that they are fostering a culture of collaboration and ensuring that their 
people are getting what they need to meet the mission of saving lives. 

B. CONCURRENT RESEARCH 

Concurrent research conducted during the same 2010-2011 timeframe as the 
research for this thesis was performed with an initial goal of understanding who works 
for who in the JIEDDO. Once the organization was mapped the process of how 
information is requested and how the requests for information are processed was 
documented in a thesis by Eieutenant Robert Gill, 2011. This thesis described the 
currently employed information management process and identified areas that could 
benefit from changes to business practices. 

In concert with the research conducted by Gill, the JTB enterprise was examined 
from a cognitive analysis aspect to understand how key personnel in the organization 
make decisions regarding what information should be shared and how they decide with 
whom to share the information. This resulted in a thesis by Major Richard EaViolette, 
2011, which revealed that the thought process behind information management decisions 
was not based upon management decisions but based on individual perceptions of what 
should be done. 
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C. THESIS GOALS 

To measure how effective the current information flow process is, and identify 
requirements that would support integrating processes and IT systems to implement best 
practices in the JTB, this research seeks to answer the following questions: 

1. Given how the JTB manages information, how well are they supporting 
combat operations? 

2. What are the requirements to make the management process more effective? 

Chapter II reviews literature supporting industry best practices in the management of 
information. Chapter III explains the methodology used for research. Chapter IV 
presents the results of this research. Chapter V describes conclusions that summarize the 
return on investment that can be gained by implementing changes and proposes areas of 
follow-on research that may be conducted to further benefit the JTB. 
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II. LITERATURE REVIEW 


Managing information within an enterprise can be a complicated process. Each 
individual organization within the enterprise shares information in a unique manner 
consistent with the culture of the organization. To manage the information held by an 
organization, you must be able to capture not only the data maintained in the 
organization’s databases, but also capture what information is shared through 
conversation, e-mail, and may other forms of communication. Examining the process 
used by the organization, provides an understanding of and insight into what makes the 
organization work and what things in the organization are not working well. Knowledge 
Management is a process that helps an organization understand itself and how it can 
make changes to improve the organization as it matures. It is also very useful in helping 
one understand how a set of organizations can improve their performance as an 
enterprise. In today’s world of Information Technology, the Knowledge Management 
processes must be considered in conjunction with Data Management processes. Analysis 
of how data is managed can support standards of format and help define underlying 
software and system design. Good requirements for system design will ensure that the 
tools used to manage data are capable of supporting users in the most efficient manner. 

A. KNOWLEDGE MANAGEMENT 

The U.S. Army defines Knowledge Management as, “The art of creating, 
organizing, applying, and transferring knowledge to facilitate situational understanding 
and decision making” (EM 3.0, 2008, p. G-9). This definition states that Knowledge 
Management is an “art.” Therefore, there is not a clearly defined process for evaluating 
the quality of a Knowledge Management program. The same Army publication defines 
Information Management as “The science of using procedures and information systems 
to collect, process, store, display, disseminate, and protect knowledge products, data, and 
information” (EM 3.0, 2008, p. G-7). The “science” of Information Management is more 
clearly delineated as a process or system that will organize data and information, but it 
does not spell out what is needed to ensure effectiveness of the system. To evaluate the 
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effectiveness of a Knowledge Management system one must have some metric to assess 
the effectiveness of the organization regarding their ability to be effective in Knowledge 
Management. “The most important characteristic to consider when choosing or defining 
a KM performance measure is whether the metric indicates if knowledge is being shared 
and used” (Hoss & Schlussel, 2009). The fact that information is available does not 
mean that users are making use of the information. Access to information may be limited 
by the fact that a user is unaware of how to access the information. 

The U.S. Army has a formal Knowledge Management program known as Army 
Knowledge Management (AKM). AKM is the U.S. Army’s strategy for Knowledge 
Management, where the goals of AKM are to: (1) adopt governance and cultural changes 
to become a knowledge-based organization; (2) integrate KM and best business practices 
into Army processes to promote the knowledge-based force; (3) manage the 
infrastructure as an enterprise to enhance efficiencies and capabilities such as 
collaborative work, decision making, and innovation; (4) institutionalize AKO/DKO as 
the enterprise portal to provide universal and secure access for the entire Army; and (5) 
harness human capital for the knowledge-based organization (Hudson, 2005). 

One of the tools available to assess the effectiveness of a command’s Knowledge 
Management program, is the AKM Maturity Indicator, which is shown in Table 1. The 
AKM Maturity Indicator is a tool that is used to evaluate Knowledge Management 
maturity from an organizational perspective. Use of the AKM assessment tool is an 
initial step to take before implementing Knowledge Management programs to decide 
what changes would be most effective (Hoss & Schlussel, 2009). 


6 



Table 1. AKM Maturity Indicator (From Hoss & Schlussel, 2009) 


AKM Maturity Indicator 

How KM Mature is Your Organization? 

Key Elements of 

1 an Integrated 
^ KM Program 

AKM PrinciDles: Peoole/Culture / Process 1 Technoloav 
KM Novice KM Mature 

1 2 3 4 5 



Culture 

What is the 
organization's 
posture towards 
adopting and 
applying the 

AKM Principles? 

3 Knowledge is 
power attitude 

3 Little sharing 
occurs 

3 Not invented 
here mentslity 

3 Change is 
discouraged 

3 Systems 

3 Knowledge 
shared within 
parts oTorg. 

3 Sharing is not 
taboo 

3 Process 
improvements 
are considered 

3 Systems beam 

□ Knowledge 
sharing exists 

□ Sharing is 
encoiraged 

3 Workers want 

efficient 

processes 

3 

balance access 

3 Knowledge 
shanng is the org. 
norm 

3 Shanng is 
expected 

3 Workers seek 

A champion 
improvements 
□ Systems use 

3 Knowledge 
shared is power 
attitude 

3 Sharing s 
rewarded 

3 Innovation is 
ertcouraged 

3 Systems cross 

all boundaries 

reside in silos 

to ooen 

and ooenness 

robust search 


Strategy 

How does the 
organization 
implement the 
AKM Principles? 

3 No KM 
strategy or plan 

3 KM not linked 
to org. success 

3 Inefficient 
processes rule 

3 r strategy not 
linked to user s 

3 KM strategy 
emerging arxj 
aligning with org. 
goals 

3 Process 
improvement 
plan developirtg 

3 IT strategy 

□ KM plans and 
governance 
model developing 

3 KM process 

assessments 

performed 

□ IT & KM 
strateoies are 

3 KM strategy 
bed to org. 
strategy 

3 KM action 
plan developed 
attd 

implemented 
□ KM strateov 

3 KM strategic 
plan in place and 
in use 

3 KM drives org. 
success 

3 Efficient 
processes rule 

3 IT supports 

needs 

considers KM 

linked 

drives IT strateov 

workers needs 

Competency 

How skilled is 
the organization 
in applying the 
AKM Principles? 

3 NoCKO/KMO 

3 Little grasp of 
KM concepts and 
methods 

3 Unsure how 
to encourage 
efficiencies 

3 L.tt:e KM too: 

3 KM champions 
emerge 

3 Interest in KM 
trainir>g growing 

3 Workers 
consider 
process 
improvements 

3 KM tool use 

□ KM champions 
lead initiatives 

□ KM Pros 
complete KM 
training courses 

□ Workers 
appty knowledge 
to improve 
processes 

□ Tool usaoe 

rses 

3 CKO/KMO 
lead KM efforts 

□ KM training 
available for all 

3 Alt wrorkers 
seek 

improvements 

□ KM tool usage 
routine 

3 Org. leaders 
drive KM adoption 
and use 

3 KM trainrig 
mandatory 

3 Continuous 
improvements 

3 KM tool usaoe 
embedded m ora. 


considered 



Metrics 

How does the 
organization 
measure the 
impact of 
applying the 

AKM Principles? 

□ KM is not a 
factor in org. 
success 

3 No metrics to 
assess KM 
impact 

3 Any existina 

3 The need to 
measure KM is 
considered 

3 KM metrics 
are used to 
baseline 
processes 

3 Metric trackino 

ootons 

considered 

a Metrics are 
considered vital to 
KM adoption and 
use 

□ KM metrics 
are used to 
validate KM 
initiatives 

□ Metres track 

□ Metrics impact 
KM inrtiatrves 

□ KM metrics 
drive process 
improvements 
a Metrics 
embedded m 

3 KM impacts 
org. success 

3 Metrics are 
part of KM 
strategy 

3 Metrics mesLv 
measure KM 

metrics used to 

systems and tools 

outcomes and are 

not outcomes 

usaoe and 




attitudes 


The key to implementing a good knowledge management program is to 
understand how the organization functions and what information is needed by the 
customer. It is important to note that the there are many types of customers throughout 
the organization and thus the KM program must recognize the needs of each customer 
and ensure that all customers are getting their requirements met. “Understanding how 

knowledge flows (or more frequently, does not flow) across these various boundaries 
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within an organization can yield critical insight into where management should target 
efforts to promote collaboration that has a strategic payoff for the organization” (Cross, 
Parker, Prusak, & Borgatti, 2001, p. 119). 

Many forms of knowledge management can be supported by the various types of 
IT systems shown in Table 2. Table 2 is not meant to be all inclusive, but it does depict 
the fact that a variety of systems can be employed to support KM (Alavi & Leidner, 
2001). It is essential that the variety of systems used for Knowledge Management be 
interoperable to ensure that data can be accessed throughout the organization. 


Table 2. Knowledge Management Processes and the Potential Role of IT (After 

Alavi & Leidner, 2001). 


Knowledge Management Processes Knowledge Creation 

Knowledge Storage / 
Retrieval 

Knowledge Transfer 

Knowledge Application 

Supporting Information 
Technologies 

Data Mining 

Learning Tools 

Electronic bulletin 

boards 

Knowledge 

repositories 

Databases 

Electronic bulletin 

boards 

Discussion forums 

Knowledge directories 

Expert systems 

Workflow systems 

IT Enables 

Combining new sources 
of knowledge 

Support of individual 
and organizational 
memory 

More extensive 

internal network 

Knowledge can be 
applied in many locations 


Just in time learning 

Inter-group 
knowledge access 

More communication 

channels available 

More rapid application of 
new knowledge through 
workflow automation 


Faster access to 
knowledge sources 


Platform Technologies _Groupware and communication technologies 


INTRANETS 


Table 2 categorizes the KM processes into four areas which helps separate the 
larger task of KM into manageable chunks. Knowledge Creation continues to evolve 
with new technologies like social networks and the accessibility of information on the 
World Wide Web. Social networks are becoming more of an extension of the social 
environment to the business environment and thus must be considered in the 
consideration of Knowledge Management. The web is but one source of Knowledge 
Storage/Retrieval, so KM must consider all sources of knowledge, and how the 
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knowledge will be stored and accessed for future use. Knowledge Transfer identifies the 
processes that support collaboration, and identifies what paths need to be available to 
support collaboration. Knowledge Application is how the user of information applies the 
knowledge to achieve results. Knowledge Application is the bottom line in KM. The 
benefit of a good KM program is applied knowledge to solve problems, to create new 
solutions and ultimately to create and share new knowledge. 

As an example, the Commander of U.S. Forces Korea directed the J6 (Directorate 
for Communications) to consolidate all of the daily sources of information into a web 
page that would provide one-stop shopping for the Commander and his staff. The web 
portal was designed with Microsoft Engineers to produce a SharePoint site that could 
host a dynamic warehouse of information to support the Commander and his many 
subordinate commands. At first, the portal was just a collection of reports posted to a 
website. With time and the Commander directing his staff to conduct their daily business 
through the portal, the portal became an essential tool for ensuring all of the staff was 
operating with the same facts and assessment of the current situation. The Sharepoint 
portal is known as the Commander’s Dashboard because the portal provides all of the 
information the Commander needs to conduct operations in a manner similar to how a 
driver of a car needs to see everything about the car on his dashboard to drive the car. 

Knowledge management is not just related to IT solutions. People have different 
cultural backgrounds, education, and experience. Knowledge management must consider 
how these differences in people affect how they collaborate and share with each other and 
whether some differences are inhibiting collaboration or enhancing it. How people 
interface with technology also affects the quality of collaboration. If technology is too 
complicated, it may wind up being a barrier to collaboration rather than a facilitator. 

B. DATABASE MANAGEMENT 

The fact that the JTB enterprise comprises a dispersed array of organizations has 
lead to many locations where data is stored. Moreover, the way the data is stored is not 
standardized throughout the organization. This lack of standardization across the 
enterprise means that a user cannot readily access information when their system is not 
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compatible with the format of the storage in another location. To understand this 
dilemma, it is necessary to define what comprises a database system. “A database system 
consists of the four components: users, the database application, the database 
management system (DBMS), and the database” (Kroenke & Auer, 2010, p. 13). The 
components of a database system are shown in Figure 1. 



Users 


Figure 1. Components of a database system (From Kroenke & Auer, 2010). 

The database is simply a list of tables containing information. The database 
management system is a software program that receives requests for information from the 
user and then uses the software to manage the information in the database. The database 
application is a computer program that interfaces between the users and the database 
management system. A query is a request for information from a database. The database 
application uses a language called Structured Query Language (SQL), which is an 
international standard by which users may access information from databases. While 
most database applications use SQL and database management systems use SQL, not all 
database management systems can work with other database management systems. In 
some cases an intermediate software program can be used to connect two different 
database management systems, but there is no guarantee that the two systems will work 
efficiently. It is therefore very important that there be a standard database management 
system throughout an organization to ensure database interoperability. In the same way, 
the manner in which the tables in the databases are constructed can affect the availability 
of information to query. For example, if one database stores phone numbers with seven 
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digits and another database uses the area code and thus uses ten digits, a query for a 
phone number would likely only generate numbers that meet the requirements of one 
format of data (Kroenke & Auer, 2010). 

Databases are huge storage devices of information. The information contained in 
databases must be accessible to the users of the information. The management of 
databases is directly tied to Knowledge Management in that collaboration between 
databases and users enables knowledge sharing. Limitations regarding the ability of 
databases to share information from one database to another directly impact the ability of 
system users to collaborate. Standardization of database management programs enables 
the sharing of existing knowledge. Collaboration amongst databases enables sharing new 
knowledge as well as storing knowledge as it is gained so that it can be applied to new 
uses. 


C. SYSTEM DESIGN 

The flow of information in the JTB enterprise is limited by the design of the 
information system. To support efficient information flow it is important to consider the 
types of system requirements and how the requirements will support the desired flow of 
information. “One method of comprehending the requirements determination process is 
by thinking of system requirements in terms of three basic types: functional, 
nonfunctional, and constraints” (Marakas, 2006, p. 80). Functional requirements support 
the system’s interactions and ultimately represent logical requirements of the system. 
Nonfunctional requirements are aspects of the system that do not represent functional 
requirements but address the visible needs of the user, i.e. a nonfunctional requirement 
may be to have the speed of processing be less than one second. The processing function 
in the design of the system is independent of the nonfunctional requirement to have the 
user wait less than a second for results. The third type of requirement, constraints or 
pseudo-requirements, are requirements put in place in the system design to satisfy user or 
system environments. Constraints may result in a system design that is less than optimal, 
but can ensure the system design will be interoperable across the enterprise. An example 
of a constraint would be that the system design utilizes the same database management 
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system across the enterprise. A new database management system may be more efficient 
in system design, but it may not be the best solution when you may have to replace all 
older systems to make the new system work with legacy systems. 

Developing system requirements necessitates a process for collecting data 
regarding information requirements prior to determination of which requirements are 
valid. Table 3 lists several examples of methods employed to gather information to 
support determination of system requirements. Similar approaches were used by Gill 
(2011) and LaViolette (2011), when conducting research on the JIEDDO. 


Table 3. Examples of Information Gathered during Requirements Determination 

(After Marakas, 2006). 


Information-Gathering Approach 

Examples 

Interview 

Current system operations 

Proposed system requirements 

Data needs 

Process sequences 

Questionnaire 

Confirmation of facts 

General user attitudes 

End-user demographics 

Focus group 

Conflicting system requirements 

Synergies across functional areas 

Observation 

Implementation of current processes 

Confirmation of interview data 

Archival document analysis 

Organizational policies and procedures 

Examples of data capture and usage 

Current system documentation 

External research 

Industry best practices 

Technological developments 

Joint application design 

Synergistic gathering of system requirements 
Identification of conflicting perspectives 

Iterative prototyping 

Refined understanding of system configuration 
Operationalization of system look and feel 
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Marakas (2006) outlined six basic characteristics for good requirements, based on 
information gathered during requirements determination, shown in Table 4. Table 4 lists 
considerations that will eliminate the cost of fixing problems later and will actually lead 
to a system that can be built. 


Table 4. Characteristics of a Well-Stated System Requirement (After Marakas, 

2006). 


Requirements Characteristic 

Description 

Testable and verifiable 

Requirement must be stated to allow for independent verification that 
the system meets or exceeds the stated requirement. 

Justifiable 

Requirement should be necessary rather than simply desirable. 

Unambiguous 

Requirement should be stated such that multiple interpretations are 
excluded. 

Consistent 

Requirement should not be in conflict with any other stated 
requirement. 

Modifiable 

Requirement should allow for changes in the business environment. 

Hierarchically traceable 

Requirement should contain a single system attribute and should be 
traceable back to a higher-level requirement. 


The process of gathering information requirements and then refining the 
requirements to ensure that they meet actual characteristics of good requirements 
involves considerable work. However, once good requirements are identified then a best 
solution can be used to build a new system or identify changes to an existing system that 
can be implemented to maximize the effectiveness of the system. Ultimately, if done 
correctly, the system design is supporting the knowledge management strategy of the 
organization. 
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III. METHODOLOGY 


Experience and training in the U.S. Navy’s Information Professional Officer 
Community indicates that developing a set of requirements for a collaborative 
information sharing enterprise environment requires Knowledge Management, use of 
databases and a System Design approach. Developing an understanding of good business 
practices is the foundation of the methodology for this research. Meetings with other 
researchers conducting concurrent studies of the JIEDDO enterprise helped to shape the 
understanding of the organization as well as focus the areas of examination. Developing 
ways to benefit from this research was the primary focus for this thesis. Working with 
the support of the JIEDDO, the assumption is that members throughout the JIEDDO 
enterprise could benefit from a better understanding of the organization and its business 
processes. The following approach was used to develop the requirements. 

A. IDENTIFY ESSENTIAL ELEMENTS OF INFORMATION 

This thesis uses the findings in Gill (2011) and LaViolette (2011) to identify key 
information elements, processes, issues, barriers, and areas for improvement in the JTB 
enterprise. Analysis of the data was made based on the belief that the enterprise can 
improve its ability to manage data and information. Indeed, the JTB enterprise already 
has several such initiatives underway. Identifying areas for improvement is not 
conducted with the intent to assign fault or blame in the manner in which the enterprise 
currently conducts business operations. This thesis was written with the intent to show 
the enterprise members what improvements can be made. Saving lives is paramount and 
if changes can facilitate preventing even one loss of life then the effort has merit. 

The JTB enterprise has capitalized on many of the best technologies to meet its 

mission. Members of the enterprise have the tools they need to do their jobs and they are 

adept at using the tools they have. This thesis will discuss ways to use the tools in a 

manner that will increase capabilities across the enterprise. It is essential to understand 

that people are the main sources of information in an organization (see Figure 2). The 

technology to collaborate is available but availability does not necessarily facilitate 
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collaboration. JTB managers need to know “who knows what” (Cross, Parker, Pmsak, & 
Borgatti, 2001, p. 108) in order to determine the potential for collaboration. The JTB 
web portal was created to be a collaboration tool for researchers and end users of the 
information stored on the portal. This thesis will describe ways the portal can be used to 
maximize the potential of the portal and ensure essential information is available when 
and wherever it is needed. 

Sources of Important Information 



Source Categories 

Figure 2. Where people go for information (From Cross, Parker, Pmsak, & Borgatti, 

2001 ) 


B. DATA ANALYSIS 

Gill (2011) and LaViolette (2011) gathered data through interviews and surveys 
with members of the JIEDDO enterprise. Each researcher in turn used these data points 
to support their conclusions. This thesis will use the data points from both theses and 
analyze the data in a different manner. The combined data points will be classified by 
type. They will be classified as being related to Knowledge Management, related to Data 
Management or a Eeadership issue. It is recognized that each data point may be related 
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to more than one classification or even all three classifications. Analysis of the data 
statistics will show the distribution of the type of issues as well as refine the data points 
into three subject areas. 

C. CLASSIFY DATA INTO SUB-CLASSIFICATIONS 

Once the data was sorted into classifications, the data points were refined into 
sub- classifications to facilitate the development of a list of requirements for those areas. 
The sub-classifications are listed in Figure 3. The Knowledge Management sub¬ 
classifications include the Army Knowledge Management principles of People, Process 
and System Perspective. These sub-classifications were chosen to be in keeping with the 
Army Knowledge Management program because the enterprise is led by the U.S. Army 
despite being a Joint enterprise. The Data Management sub-classifications include the 
requirement types of Functional, Nonfunctional and Constraints. The Data Management 
sub-classifications were chosen to support to classifying issues into actions that support 
the design of the system, the features of the system or limitations of the system. The 
Leadership sub-classifications are Organizational, Policy and Perception. The 
Leadership sub-classifications were chosen for their areas of action required by the 
leadership of the organization to address those issues. Organizational issues are unlikely 
to be actionable without changes to the organization. Policy issues can be addressed with 
the publishing of policy. Perceptions are beliefs that leadership can address directly 
through communication with the members of the enterprise. 
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Figure 3. Data Sub-Classifications 


D. GROUP SUB-CLASSIFICATION ISSUES INTO REQUIREMENTS 

Once the data was sorted into sub-classification categories the tables listing issues 
in each sub-classification were refined into specific lists of requirements for that area. 
The process of adapting the tables into a more refined list eliminated redundant data 
points and consolidated like issues into actionable requirements. 

E. ORGANIZE REQUIREMENTS INTO ACTION ITEMS LIST 

Once the list of requirements was generated for each sub-classification area, the 
requirements were then translated into action item lists for the JTB enterprise to use to 
address the issues. The lists were developed to provide specific tasks that can be 
completed to mitigate the issues and capitalize on the findings of this thesis. 
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IV. ANALYSIS AND RESULTS 


Analysis of the results provided by Gill (2011) and LaViolette (2011) identified 
197 qualitative data points. These data points were classified into categories and the 
results are listed in Table 5. Note that many data points could be classified into more 
than one category therefore the percentages add up to more than 100%. 


Table 5. Qualitative Data Points assessed by subject area 



Knowledge 

Management 

Data Management 

Leadership 

Qualitative Data Points 
assessed by subject area 

95.40% 

25.40% 

73.60% 


The qualitative data points were then classified further within the subject areas to 
clarify specific actions required to address the data point. Knowledge Management was 
broken into the AKM principles listed in Table 1, People, Process, and System 
Perspective. The results are listed in Table 6. 


Table 6. Knowledge Management Data Points assessed by AKM Principles 



People 

Process 

System Perspective 

KM Data Points assessed 
by AKM principles 

19.10% 

60.60% 

20.20% 


The Data Management Data Points were classified by the system design 
requirements of Functional, Nonfunctional, and Constraints, and these results are 
presented in Table 7. 
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Table 7. Data Management Data Points assessed by requirement type 



Functional 

Nonfunctional 

Constraints 

DM Data Points 
assessed by 
requirement type 

22.20% 

61.10% 

16.70% 


The Leadership Data Points were classified by subject area as being an 
Organizational, Policy, or Perception related issue and the results are listed in Table 8. 


Table 8. Leadership Data Points assessed by Subject Area 



Organizational 

Policy 

Perception 

Leadership Data 
Points assessed by 
subject area 

4.10% 

82.80% 

37.90% 


The results are discussed by subject area to show how each issue leads to the 
recommended requirements. 

A. SUBJECTS 

1. Knowledge Management 

The Army Knowledge Management Principle of People or Culture addresses 
issues that represent the command climate and can greatly enhance or reduce productivity 
within an organization. Examination of the data regarding the principle of People or 
Culture revealed that most issues involve needing information or cooperation. These 
results are listed in Table 9. Results of this examination of the data identified four 
positive points: (1) everything is done for the warfighters, and they are appreciative of it; 
(2) everyone has emotional ties to making sure the warfighters are safe; (3) information 
required for budgeting is received quickly; and (4) most people get the amount of 
information they need. 
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Table 9. Knowledge Management People Data Points by Aspect 



Aspect 

Need Information 

Need Contacts 

Need Cooperation 

Positive 

KM People 
Data Points 

13 

3 

16 

4 

% of Total 

36.10% 

8.30% 

44.40% 

11.10% 


a. People 


Quantifying all of the user needs for information is not an easy task. Each 
user has different requirements for information to achieve their mission. Analysis of the 
Knowledge Management People data points regarding those who need information 
showed that trust and sharing are major concerns within the enterprise. The comments 
related to need information are listed in Table 10. 


Table 10. KM People Data Points Aspect: Need Information 


KM People Data Points Aspect: Need Information 

Sharing is often contingent upon who you know 

Sharing is based on the 'good ole boy' system 

Personal relationships get access to information 

Sometimes an ultimatum is necessary, even if others know the information is required 

Testers and range workers fear losing their jobs 

Lack of trust throughout the organization 

People don’t know who to ask for what information 

When sharing occurs, the amount of information received is inadequate 

People are reserved in large video teleconferences because they are not willing to share 
information with all of the participants 

Individuals don’t know who has what information 

Make sure everyone is aware of all available resources 

Falsely assuming that others have access to the same information 

End users have not heard of or about JTB, however most have heard of JIEDDO 
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The contents of Table 10 can be reduced to the following three 

requirements: 

• Sharing information within the enterprise must be a standard that is 
enforced by command policy 

• Command organization, mission, and strategy must be visible and 
accessible to all members of the enterprise 

• Knowledge must be managed throughout the enterprise and 
support the needs of the warfighter 

Command climate or culture can affect how well people are able to 
interact with each other across the offices or throughout a dispersed organization. 
Analysis of the data indicates there is a need for better contact lists as well as a 
mechanism for people to find new contacts when working with the myriad of 
organizations while supporting the warfighters. This point is also a data storage issue as 
the contact lists need to be in the information system so that all users can access lists for 
contacting supporting personnel. The need contact comments are listed in Table 11. 

Table 11. Knowledge Management People Data Points Aspect: Need Contacts 

KM People Data Points Aspect: Need Contacts 

Personal relationships lead to points of contact 

Personal relationships get assets 

Attending conferences to develop personal relationships and 
establish points of contact 

The contents of Table 11 can be reduced to the following two 

requirements: 

• A comprehensive directory of personnel must be published and 
maintained for use of all personnel throughout the enterprise 

• Collaboration and networking must be encouraged through policies 
and practice 

Command climate is often driven by command policy as well as members 
of the command seeing policy enforced throughout the organization. In the case of 
JIEDDO, the organization is comprised of many entities that are perceived as competition 
and that has resulted in some concerns of job security and a lack of unity amongst the 
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organizations. Recognizing these issues should help the command understand that it 
needs to make a policy that will support all of the command personnel and allay their 
fears. The need for cooperation comments are listed in Table 12. 


Table 12. Knowledge Management People Data Points Aspect: Need Cooperation 


KM People Data Points Aspect: Need Cooperation 

Individuals hoard information to make themselves seem more powerful 

Individual biases 

Some individuals share only what is requested, despite knowing more is required 

Individuals don’t see themselves as part of an enterprise 

Belief throughout the organization that sharing information may result in losing 
business to another organization 

Sharing information is helping your competition, which puts your job at risk 

Individuals don't share in order to avoid being judged by their peers 

The belief that the info is mine so no one else can interpret it 

Individuals will use information in the central repository correctly if their interest is to 
help the guys overseas 

Individual's fear of data being misused 

Managerial resistance to obtaining data from another organization 

Management intervention is often necessary to require others to share information 

Some individuals don’t know there is a necessity to share 

Rivalries between sites and services create barriers 

Build trust with JIEDDO modeling and simulation 

People get the information they need only after working through barriers 


The contents of Table 12 can be reduced to the following three 


requirements: 

• Clarify if competition is required amongst commands within the 
enterprise 

• Strengthen the teamwork concept by using the one team ethos 

• Clarify what information is proprietary and what information is 
required to be shared within and outside the enterprise 

b. Process 

The Army Knowledge Management Principle of Process addresses how 
command processes are aiding or restricting the knowledge flow through the 
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organization. Process Data Points were classified by aspect and the results are listed in 
Table 13. Examination of the data regarding this principle revealed that most issues 
involve needing policy, though there is also a need for information and meetings. The 
data identified five positive aspects: (1) weekly status reports are done and recorded; (2) 
analysis metrics and test design information are often shared between organizations; (3) 
working groups are a good start to communicating between ranges; (4) some 
commonality of requirements exists between test ranges; and (5) the RFI Process in place 
is efficient. 


Table 13. Knowledge Management Process Data Points by Aspect 



Aspect 

Need Training 

Need Information 

Need Meetings 

Need Policy 

Positive 

KM Process 
Data Points 

10 

29 

20 

50 

5 

% of Total 

8.80% 

25.40% 

17.50% 

43.90% 

4.40% 


In any organization, there is always a need for training. Users of 


information must have a good understanding of how to use the established processes to 
gain the information they need. Feedback from training and new personnel can help to 
shape training programs to ensure that the training meets the user’s needs. The need for 
training comments are listed in Table 14. 
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Table 14. Knowledge Management Process Aspect: Need Training 

KM Process Aspect: Need Training 

People don’t know all the individuals and personalities, so they have a 
difficult time receiving the information they need 

Information is generally requested from unknown points of contact 
Sharing establishes relationships that make it easier to share again 
Protect the warfighter by ensuring that information is not taken out of 

context _ 

Requirements levied on individuals change frequently 

Protocols are open to interpretation 

High rate of personnel turnover 

The JTB is an Enterprise within a larger enterprise 

End users get information from sources other than JTB 

JTB interact with the end users either indirectly or not at all 

The contents of Table 14 can be reduced to the following three 

requirements: 

• Training is required for members to understand the roles and 
responsibilities of the enterprise and the organizations within the 
enterprise 

• Training is required to ensure members are cognizant of and 
understand command policies and changes to policies 

• Training is required to clarify the process to account for changes to 
personnel in key positions and who to approach when a position is 
not filled. 

Knowledge Management Processes are inherently about the ability to get 
information, share information, or store information. Understanding the process is often 
the most challenging aspect of obtaining information. Transparency of the process can 
assist people in their process for obtaining the information they need. Part of the 
challenge is to write policies that ensure the process supports the need for collaboration 
where the biggest challenge is to manage the change in the organization to ensure new 
process are being affected per the command policy. Comments regarding the need for 
information also contain suggestions for sharing information and they are listed in Table 
15. 
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Table 15. Knowledge Management Process Aspect: Need Information 


KM Process Aspect: Need Information 

Getting information depends on personal relationships 

Most tests are set up as individual tests to be conducted at a single range 

Create a position to consolidate and distribute information and updates from working groups 

Geographical distribution of JTB organizations challenges information sharing 

Create a collective situational awareness for the organization 

Decisions are made in a risk averse environment 

Guidance from higher leadership 

Data being collected by the program office needs to be shared with the JTB 

Sharing information with modeling and simulation may lead to better models and less open air testing 

Can’t figure out who to talk to for certain information 

Publish a complete organizational chart that includes individuals, their expertise, and contact 
information 

Create and disseminate a point of contact list for each organization 

JTB needs to establish points of contact at each test location that can help to get people the right test 
data that they need to be sharing 

Information received is not normally timely or accurate, which leads to getting the information through 
different means 

Some organizations attempt to repress certain information if it might be harmful to a system 

Working groups should do a better job of letting others know what information they have to share 

Working group members don’t disseminate what they learn with co-workers 

End user support falls within JIEDDO 

Single points of failure in communications 

Need some sort of JTB centric marketing in order to promote products and mission 

JIEDDO has a very informative Eacebook page, JTB can either promote itself through the JIEDDO 
page or create one of their own social networking site 

Eacebook page would promote JTB 

Eacebook page would be an UNCLAS way to keep in touch with end users and keep them informed on 
JTB activities 

End users would like a pamphlet which would have the most updated test results 

Quarterly newsletter? 

Get actionable information and disseminate 

No evidence that post event analysis directly influences the infrastructure in a near real time manner 

Only direct link b/w JTB and end user is a one week pre deployment training 

End users would like are interested in gaining more information 


The contents of Table 15 can be reduced to the following three 

requirements: 

• Information must be managed by a person in a position that 
supports information sharing across the entire enterprise 

• Process is needed to identify when personnel in key positions leave 
and document who will assume the responsibilities when a person 
does leave 
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• Knowledge gained through meetings, testing, or new directives 
should be published on a regular schedule to ensure the knowledge 
is shared throughout the enterprise 

Collaboration increases team effectiveness and the opportunity exists for 
more collaboration across the JIEDDO enterprise. The need for meetings is a strong 
indication that members of the enterprise want to be better at collaboration. Their 
comments suggest that they recognize the effectiveness of meetings and hope to bring 
together the team through meetings in person, video teleconferencing or telephone 
conversations. The comments on the need for meetings are listed in Table 16. 


Table 16. Knowledge Management Process Aspect: Need Meetings 


KM Process Aspect: Need Meetings 

Working group networking 

Conduct an offsite to give people the chance to get to know each other 

Physical collocation of leadership enables better communication 

The reduced number of working groups results in less personal interaction 

Get the JTB leadership together to make sure that everyone is on the same page 

Reinstate JTB run range worker meetings 

JTB employees should visit all of the organizations to understand how they work 

Continue to have projects where different test ranges work together 

Physical collocation of testers from multiple ranges 

Multiple ranges cooperating on a single test 

Face to face groups enhance sharing 

Getting together to solve problems 

Weekly SVTCs 

Increase use of the telephone for discussions 

Weekly meetings 

Secure Video Teleconference 

Hold annual IT review across enterprise to discuss IT issues 

JTB will need to work with partners to identify and produce relevant information to the end user 

End users would like feedback through debriefs 

EW officer of the week to weekly meetings 


The contents of Table 16 can be reduced to the following four 

requirements: 


• Document the current schedule of meetings within the enterprise, 
the purpose of each meeting, the format of each meeting 
(teleconferences, VTC, etc), state who should attend each meeting 
and publish the information to the enterprise 

• Develop a feedback process for adding or changing meetings and 
publish policy to the enterprise 
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• Document and share meeting agendas and meeting minutes to 
encourage knowledge sharing throughout the enterprise 

• Document what meetings take place with entities outside the 
enterprise and develop a feedback mechanism for entities outside 
the enterprise to provide customer feedback. 

Policies, regulations, and procedures are the backbone of an organization. 
In a traditional command structure the organizational policies would be in place that had 
been refined over time to meet the needs of the organization. In the case of JIEDDO, the 
organization was developed within the last five years to counter the serious threat of 
lEDs. With any new organization there will be a need to adapt to new and unforeseen 
challenges. Because the structure of JIEDDO is unique, it is natural that there will be 
some unique needs for policies to govern the actions of the organization. The Knowledge 
Management Process list of the need policy comments are listed in Tables 17 and 18. 


Table 17. Knowledge Management Process Aspect: Need Policy Part 1 


KM Process Aspect: Need Policy 

Maintain organizational reputation by preventing misuse of data by other organizations 

Share because it is required to get the job done 

Share to clarify information 

Sharing information to improve everyone's performance. It doesn't matter who takes 
the credit, as long as the job is done right 

Share so everyone can benefit 

Institutionalized financial resource competition between test ranges stops information 
sharing 

Bureaucracy has made the organization ineffective 

JTB organization is constantly changing 

JTB should provide cleaner roles for testing organizations 

Requirements continually change 

Creating an environment that is open to sharing and protects proprietary interests 

Internal review by JIEDDO 

Test ranges have different priorities than the JTB because they have to work with other 
customers to obtain additional financial resources 

No commonality of a strategic plan between ranges or from higher 

The lack of a written Information Sharing policy results in confusion through reliance 
on a set of unwritten norms that individuals interpret differently 

Create an information sharing policy for the JTB 

Create process maps for data flow processes, infrastructure, and research & 
development 
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KM Process Aspect: Need Policy 

Formalize the information sharing processes 


Establish the processes for coordination 

There is no process in place to share information 

Create procedures for information to flow from all locations to a central repository 

Creating standard operating procedures within departments 

There are no formal procedures for information sharing 

No common data schema or data collection formats 

Develop overarching protocols 

There is no standard method or format for requesting, collecting, storing, or 
disseminating data 

Standardize the file format of the most commonly used test data 

Create a written set of guidance for continuity for each position in order to lessen the 
impact of personnel turnover 

Access controls on who can post to the JTB portal increase trust in the posted 
information 

Restrict access to information to individuals who know what to do with the information 
so everyone is willing to share 


Meetings that include coalition partners restrict some communications 


Table 18. Knowledge Management Process Aspect: Need Policy Part 2 

KM Process Aspect: Need Policy _ 

Much of the information gathered is proprietary and not shared _ 

Work within the constraints of the POD Directive _ 

Synchronize and coordinate JIEDDO testing process _ 

Minor changes to RFI process could be instituted while keeping integrity of process 

Institute a feedback loop in the RFI process _ 

Processes need to reach across enterprise _ 

Processes do not have any policy or guidance to how they work _ 

Need to capture and document current process in order to write guidance which would 

mirror RFI process _ 

Last entry on JTB portal bulletin boards was over a year ago _ 

Some JTB portal bulletin boards haven’t been posted to since 2009 _ 

Test agencies have ability to post reports to portal but don’t _ 

Knowledge and Information Networking Group (KING) administers and maintains 

portal based on what guidance _ 

KING develops spreadsheets to display test results _ 

Test agencies, theater support organizations, end users and KING need to work together 
in order to develop product for an E-5_ 
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KM Process Aspect: Need Policy _ 

Turn test results into actionable information _ 

Information Czar - CIO _ 

Design IT Policy and protocol for portal usage _ 

IT management must have authority across enterprise _ 

The contents of Table 17 and 18 can be reduced to the following nine 


requirements: 

• Publish list of current policies and changes 

• Create policy on sharing 

• Create policy on testing requirements 

• Develop a map of data flow for processes throughout the enterprise 
architecture and within the research and development process and 
provide training on the processes 

• Create a standard operating procedure for information to get to and 
from a central data repository 

• Create standard operating procedures for each department 

• Create a policy establishing standardized file formats 

• Document position descriptions to identify positional 
responsibilities to lessen impact of personnel turnover 

• Mandate use of the JTB portal for collaboration 


c. System Perspective 


The Army Knowledge Management Principle of System Perspective or 
Technology addresses how command IT systems are supporting users or limiting their 
ability to complete their missions. System Perspective Data Points were classified by 
aspect and the results are listed in Table 18. Examination of the data regarding aspect 
revealed that there is need for additional requirements and some adjustments to existing 
features of the system. The data identified 26.3 percent of the data points as in fact 
positive aspects of the existing system. 
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Table 19. Knowledge Management System Perspective Data Point by Aspect 



Aspect 

Need Requirement 

Need Adjustment 

Positive 

KM System Perspective 
Data Points 

15 

13 

10 

% of Total 

39.50% 

34.20% 

26.30% 


The JIEDDO web portal is a critical tool for collaboration across the 


JIEDDO enterprise. Combining the Web portal with other communication systems 
throughout the enterprise should provide more access to information and should reduce 
the number of the Requests Eor Information by allowing users direct access to the 
information. A review of the information systems revealed areas that users indicated 
could use some adjustments. The list of needs adjustment comments are listed in Table 
20 . 


Table 20. Knowledge Management System Perspective Aspect: Needs Adjustment 


KM System Perspective Aspect: Needs Adjustment 

Theater Support Web Tool is not user friendly 

Transitioning to a new Oracle database 

There are issues with permissions in the information system 

Redundant posting on the Theater Support Web Tool and JTB Portal 

There is a lack of access to information from other facilities and ranges 

There is a lack of access to documents that are known to be available to others 

Not being able to access other ranges database for information 

Obtaining raw unfiltered data from a test range is a challenge 

Eack of visibility on updated documents 

Inability to locate documents that are known to exist in other organizations 

End users would like background info 

End users would like the history of the evolving threat 

End users would like better “circles” based on detailed analysis 


The contents of Table 20 can be reduced to the following five 


requirements: 
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• Create a single sign on for the JTB Portal and all websites within 
the JTB enterprise 

• Create a customer feedback survey on the JTB portal 

• Create a link to a list of recently updated documents on the JTB 
portal 

• Create a Frequently Asked Questions link to document common 
lED queries 

• Create a contact list by subject area for people to contact for more 
information on a subject area 

From a system perspective, requirements are fundamental functions that 
users need to make the system more capable of supporting the user needs. Much like the 
data management aspect of functional requirements, Knowledge Management System 
Perspective requirements are basic level functions that are essential for system operation. 
The list of needs requirements comments are listed in Table 21. 


Table 21. Knowledge Management System Perspective Aspect: Needs Requirement 


KM System Perspective Aspect: Needs Requirement 

Tying together IT infrastructure 

High quality hyperlinks from the JTB portal 

The JTB portal should include: climate data, atmospheric conditions, time, space, 
and position information 

Add a selectable pop-up notice within the JTB portal 

Test result availability on the Theater Support Web Tool 

Create a common data store between the JTB and JIEDDO 

Create a multi-security-level database that links data within reports at different 
levels 

Create a central data repository where everyone collects, shares, and presents data in 
a similar fashion 

A central repository should include: scenario data, environmental conditions, 
performance data, representation of the sensor for instrumentation, test plans, and 
test reports that constitute every data element or data record 

The enterprise lacks a good central repository that has all the metadata and the data 
required to make use of the information 

Establishing a threat database to track threat resources and their status 

An easy to use well implemented web interface 

Creation of a database 

Static e-mail addresses (i.e. TEP_ewo@e-mail.smil.mil) 

Need a REI Tracking mechanism 
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The contents of Table 21 can be reduced to the following four 

requirements: 

• Data systems throughout the enterprise should be connected and 
interoperable 

• Create multiple security level accesses to databases 

• Create e-mail accounts for positions or offices to ensure 
deliverability despite personnel turnovers 

• The Request for Information process should require a point of 
contact for the request and then update the person requesting the 
information when there is a change to the RFI 

JTB does not have a person designated to be the enterprise knowledge manager. 
If there is not a designated person responsible for ensuring that the enterprise is following 
a knowledge management plan, then the there is no enterprise knowledge management. 
Management at lower levels is conducted without complete knowledge of the 
organizational structure. Some managers are not aware of the roles and responsibilities 
of key positions across the enterprise. The JTB is not managed as a whole; rather it is 
managed as a disparate group of independent entities that function with limited 
interaction amongst the entities. The JTB portal is the main tool for collaboration 
amongst the commands under the JTB. However, there is little indication that the 
commands are using the information that is posted on the portal. There are bulletin 
boards hosted on the portal that have had very few postings in the last three years. The 
portal is not user friendly and requires training to understand how to get the information 
you need. The portal is meant to facilitate access to many sources of information yet 
each source requires a unique user name and password that must be obtained in order to 
access the content of the source. Much like the JTB organization, the portal needs to be 
managed to ensure knowledge is accessible to those who need information. Users of JTB 
information obtain the information from sources at the battalion level or lower, often 
relying on “gouge” from someone leaving the theater. There is no one location for a 
person with a need to access a collection of information on lEDs. From a knowledge 
management perspective the following recommendations are made: 
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• Designate a person who is accountable for KM in the JTB (CIO) 

• Designate a person at each command who will be responsible for KM and 
reports to the JTB KM to support KM throughout the enterprise 

• Implement the AKM program 

2. Data Management 

System design attributes are defined as requirements that are either functional, 
nonfunctional, or constraints. Categorizing system requirements by functional or 
nonfunctional indicates that the requirement directly supports the system design 
(functional) or the requirement support user needs (nonfunctional). Constraints also 
address user needs but they may have the effect of limiting the functional capability of 
the system to meet a constraint. The Data Management Functional requirement 
comments are listed in Table 22. 


Table 22. Data Management Functional Data Points 


Data Management Functional Data Points 

No common data schema or data collection formats 

There is no standard method or format for requesting, collecting, storing, or 
disseminating data 

Standardize the file format of the most commonly used test data 

The JTB is creating a common server environment that will attach people at all 
locations 

JTB portal 

Transitioning to a new Oracle database 

Create a common data store between the JTB and JIEDDO 

Create a central data repository where everyone collects, shares, and presents data in a 
similar fashion 

A central repository should include: scenario data, environmental conditions, 
performance data, representation of the sensor for instrumentation, test plans, and test 
reports that constitute every data element or data record 

The enterprise lacks a good central repository that has all the metadata and the data 
required to make use of the information 

Establishing a threat database to track threat resources and their status 

Creation of a database 
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The contents of Table 22 can be reduced to the following two requirements: 

• Create a position for Data Management with the authority to make 
policy for the enterprise 

• Create policy for the format of data, the storage of data and the 
sharing of data 

Nonfunctional data requirements are system attributes that support user needs, but 
do not represent requirements that affect the system functionality. Nonfunctional 
requirements are more like features of a system vice functions. They represent 
adjustments to the system to provide users with data in a manner that is more supportive 
of their needs. The nonfunctional requirement comments are listed in Table 23. 


Table 23. Data Management Nonfunctional Data Points 


Data Management Nonfunctional Data Points 

People don’t know all the individuals and personalities, so they have a difficult time receiving the 
information they need 

Getting information depends on personal relationships 

Information is generally requested from unknown points of contact 

Points of contact for the Knowledge Integration and Networking Group are on the top of the page of the 

JTB Portal 

Share to clarify information 

Data being collected by the program office needs to be shared with the JTB 

Weekly status reports are done and recorded 

Analysis metrics and test design information are often shared between organizations 

Publish a complete organizational chart that includes individuals, their expertise, and contact information 

Create and disseminate a point of contact list for each organization 

JTB needs to establish points of contact at each test location that can help to get people the right test data 
that they need to be sharing 

High quality hyperlinks from the JTB portal 

Read Me files are available for everything on the JTB portal 

The JTB portal should include; climate data, atmospheric conditions, time, space, and position information 

Add a selectable pop-up notice within the JTB portal 

Theater Support Web Tool is not user friendly 

There are issues with permissions in the information system 

Test result availability on the Theater Support Web Tool 

An easy to use well implemented web interface 

Theater Support Web Tool 

Obtaining raw unfiltered data from a test range is a challenge 

Individuals don’t know who has what information 

Make sure everyone is aware of all available resources 

Lack of visibility on updated documents 

Inability to locate documents that are known to exist in other organizations 

Static e-mail addresses (i.e. TFP_ewo@e-mail.smil.mil) 

Need a RFI Tracking mechanism 
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Data Management Nonfunctional Data Points 

None of JIEDDO SIPR websites are linked to JTB _ 

Each working group has ability to post information on the JTB Portal _ 

End users would like background info 

End users would like the history of the evolving threat _ 

End users would like better “circles” based on detailed analysis _ 

End users would like are interested in gaining more information _ 

The contents of Table 23 can be reduced to the following four requirements: 

• Each website should have a point of contact for information 
contained on the web page 

• Require the posting of weekly status reports to the portal 

• Permissions to access web content should be managed by one point 
of contact 

• Add information Links to websites outside of the enterprise 

Constraints in system design represent limits to a system’s ability to function in a 
way that will meet requirements. Constraints reduce the maximum capability of a 
system. Constraints limit functionality but add capabilities like security restrictions or 
interoperability of systems with other systems. Ultimately the application of constraint 
requirements increases the user capabilities of the system though it may reduce system 
functionality. Constraint requirement comments are listed in Table 24. 


Table 24. Data Management Constraints Data Points 

Data Management Constraints Data Points 

Maintain organizational reputation by preventing misuse of data by other 

organizations _ 

Tying together IT infrastructure 

JTB portal home page designed as a wheel for easy access to all aspects of the 
organization 

Access controls on who can post to the JTB portal increase trust in the posted 
information 

Create a multi-security-level database that links data within reports at different levels 
There is a lack of access to information from other facilities and ranges 
There is a lack of access to documents that are known to be available to others 
Not being able to access other ranges database for information 

Restrict access to information to individuals who know what to do with the 
information so everyone is willing to share 
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The issues identified in Table 24 have been addressed by requirements developed 
from earlier tables. The issues are all linked to the need for consistent data management 
processes and procedures throughout the enterprise. With consistent policies and 
procedures the issues of access can be addressed on an individual basis to ensure data is 
shared in a manner consistent with the command policy. 

To move information across networks spread throughout the world it is necessary 
to have a foundation to build upon. Each organization must use the same standards for 
data in order for the systems to be able to use the data from other systems. The JTB does 
not have someone designated as the Chief Technology Officer (CTO). In a military 
command structure there would be a N6 for a Navy command or a J6 in a Joint 
command. That person would be accountable for communication systems and they 
would ensure that all subordinate commands used communication standards to ensure 
data interoperability. Standards are essential if databases are going to share information. 
The CTO can direct standards for web content and ensure that information posted to 
websites can be accessed by those who need the information. The JTB portal content 
should be managed with KM perspective. The RFI process identified in Gill (2011), is 
conducted through a website, but the process does not document who requested the 
information, how to contact the person requesting the information, nor document an 
approval process for expending funds to support the request for information. From a 
systems management perspective, the JTB needs the following requirements: 

• Designate a CTO who is accountable for communication systems 
throughout the JTB. 

• Designate someone at each command who is accountable for 
communication systems and accountable to the JTB CTO. 

• Adopt one standard for databases throughout the JTB. 

• Have one login for the JTB portal and be able access all content in 
the JTB through the portal vice multiple logins. 

• Apply AKM principles to web hosted content to ensure the proper 
management of the information. 
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3. Leadership 


The leadership aspects of the data points are defined as being Organizational, 
Policy or Perception. The reason for the distinction of the three aspects is to organize the 
data into areas of concern that can be addressed as separate issues. The Organizational 
Data Points are issues related to the structure of the organization as well as how the 
structure is supported. Organizational comments are listed in Table 25. 


Table 25. Leadership Organizational Data Points 

Leadership Organizational Data Points 

The JTB does not have sole authority over its component organizations, which results in 
a lack of unity of leadership and purpose 

Physical collocation of leadership enables better communication 
Organizations are managed as "stovepipes" 

JTB organization is constantly changing 

The JTB is an Enterprise within a larger enterprise 

Need Information Czar - CIO 

The contents of Table 25 can be reduced to the following three requirements: 

• Organization must have clear and defined authority over 
subordinate organizations 

• Organization must have a position for Knowledge Manager/ Chief 
Information Officer to support effective knowledge sharing 
throughout the entire enterprise in accordance with the Army 
Knowledge Management regulations 

• Organization must have a position for Information Technology 
Manager/ Chief Technical Officer to create and enforce technology 
policies and procedures to ensure compliance with Department of 
Defense standards 

Leadership Policy is by far the largest section of the Leadership Data Points. 
Many of the data points listed in the Knowledge Management section on need policy are 
repeated in this section. The data points are both Knowledge Management and 
Leadership issues in that the issues must be addressed in written policy and in the daily 
actions carried out by the leadership in the organization. Written policy is important but 
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it does not translate into real change without leadership championing the change. The 
Leadership Policy comments are listed in Tables 26 through 28. 

Table 26. Leadership Policy Data Points Part 1 

Leadership Policy Data Points 

Individuals hoard information to make themselves seem more powerful _ 

Sharing is based on the 'good ole boy' system _ 

Sometimes an ultimatum is necessary, even if others know the information is required _ 

Some individuals share only what is requested, despite knowing more is required _ 

Everyone is trying to secure funding _ 

Attending conferences to develop personal relationships and establish points of contact _ 

Conferences _ 

Working group networking _ 

Conduct an offsite to give people the chance to get to know each other _ 

Belief throughout the organization that sharing information may result in losing business to another 

organization _ 

Maintain organizational reputation by the provider restricting sharing to only those who he believes 

understand what to do with the information _ 

Sharing information is helping your competition, which puts your job at risk _ 

Maintain organizational reputation by preventing misuse of data by other organizations _ 

Share because it is required to get the job done _ 

Share so everyone can benefit _ 

Organizational culture based on reaction to requirements from the war fighter means inherent flexibility 

Institutionalized financial resource competition between test ranges stops information sharing _ 

Most tests are setup as individual tests to be conducted at a single range 

Create a position to consolidate and distribute information and updates from working groups _ 

Bureaucracy has made the organization ineffective _ 

Organizations are managed as "stovepipes" _ 

The reduced number of working groups results in less personal interaction _ 

Managerial resistance to obtaining data from another organization _ 

Requirements continually change _ 

Requirements levied on individuals change frequently _ 

Management intervention is often necessary to require others to share information _ 

Some individuals don’t know there is a necessity to share _ 

Create a collective situational awareness for the organization 

Get the JTB leadership together to make sure that everyone is on the same page _ 

Creating an environment that is open to sharing and protects proprietary interests _ 

Guidance from higher leadership _ 

Reinstate JTB run range worker meetings _ 

Data being collected by the program office needs to be shared with the JTB _ 

Organizational barriers exist between services 

Rivalries between sites and services create barriers _ 

Sharing information with modeling and simulation may lead to better models and less open air testing _ 

Internal review by JIEDDO _ 

JTB employees should visit all of the organizations to understand how they work _ 

Test ranges have different priorities than the JTB because they have to work with other customers to obtain 
additional financial resources 
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Table 27. Leadership Policy Data Points Part 2 

Leadership Policy Data Points _ 

Continue to have projects where different test ranges work together 

Physical collocation of testers from multiple ranges _ 

Multiple ranges cooperating on a single test _ 

Face to face groups enhance sharing _ 

Getting together to solve problems _ 

Working groups are a good start to communicating between ranges _ 

Weekly SVTCs _ 

Increase use of the telephone for discussions 

No commonality of a strategic plan between ranges or from higher _ 

The lack of a written Information Sharing policy results in confusion through reliance on a set of unwritten 
norms that individuals interpret differently 
Create an information sharing policy for the JTB 

Create process maps for data flow processes, infrastructure, and research & development _ 

Formalize the information sharing processes _ 

Establish the processes for coordination _ 

There is no process in place to share information _ 

Create procedures for information to flow from all locations to a central repository _ 

Creating standard operating procedures within departments _ 

There are no formal procedures for information sharing _ 

No common data schema or data collection formats _ 

Develop overarching protocols _ 

Protocols are open to interpretation _ 

Some commonality of requirements between test ranges _ 

There is no standard method or format for requesting, collecting, storing, or disseminating data _ 

Publish a complete organizational chart that includes individuals, their expertise, and contact information 

Create and disseminate a point of contact list for each organization _ 

JTB needs to establish points of contact at each test location that can help to get people the right test data 

that they need to be sharing _ 

High rate of personnel turnover _ 

Significant turnover in JTB leadership _ 

Create a written set of guidance for continuity for each position in order to lessen the impact of personnel 

turnover _ 

Information received is not normally timely or accurate, which leads to getting the information through 
different means 

When sharing occurs, the amount of information received is inadequate _ 

Information required for budgeting is received quickly _ 

The JTB is creating a common server environment that will attach people at all locations _ 

Access controls on who can post to the JTB portal increase trust in the posted information _ 

JTB portal _ 

There are issues with permissions in the information system _ 

Create a common data store between the JTB and JIEDDO _ 

Weekly meetings _ 

Secure Video Teleconference _ 

Email (NIPR and SIPR) _ 

Telephone _ 

There is a lack of access to information from other facilities and ranges _ 
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Table 28. Leadership Policy Data Points Part 3 

Leadership Policy Data Points _ 

There is a lack of access to documents that are known to be available to others 

Not being able to access other ranges database for information _ 

Obtaining raw unfiltered data from a test range is a challenge _ 

Restrict access to information to individuals who know what to do with the information so everyone is 
willing to share 

Meetings that include coalition partners restrict some communications _ 

Some organizations attempt to repress certain information if it might be harmful to a system _ 

Much of the information gathered is proprietary and not shared 

Individuals don’t know who has what information _ 

Make sure everyone is aware of all available resources _ 

Falsely assuming that others have access to the same information _ 

Working groups should do a better job of letting others know what information they have to share _ 

Working group members don’t disseminate what they learn with co-workers _ 

Inability to locate documents that are known to exist in other organizations _ 

Work within the constraints of the POD Directive _ 

Synchronize and coordinate JIEDDO testing process _ 

End user support falls within JIEDDO _ 

Processes need to reach across enterprise _ 

Processes do not have any policy or guidance to how they work _ 

Need some sort of JTB centric marketing in order to promote products and mission _ 

JIEDDO has a very informative Eacebook page, JTB can either promote itself through the JIEDDO page or 

create one of their own social networking site _ 

Eacebook page would promote JTB _ 

Eacebook page would be an UNCLAS way to keep in touch with end users and keep them informed on JTB 

activities _ 

Quarterly newsletter? _ 

None of JIEDDO SIPR websites are linked to JTB _ 

Last entry on JTB portal bulletin boards was over a year ago _ 

Some JTB portal bulletin boards haven’t been posted to since 2009 _ 

Test agencies have ability to post reports to portal but don’t _ 

Knowledge and Information Networking Group (KING) administers and maintains portal based on what 

guidance _ 

Test agencies, theater support organizations, end users and KING need to work together in order to develop 
product for an E-5 

Turn test results into actionable information _ 

Information Czar - CIO _ 

Hold annual IT review across enterprise to discuss IT issues 

Design IT Policy and protocol for portal usage _ 

IT management must have authority across enterprise _ 

Only direct link b/w JTB and end user is a one week pre deployment training _ 

JTB interact with the end users either indirectly or not at all _ 

JTB will need to work with partners to identify and produce relevant information to the end user 

End users would like feedback through debriefs _ 

EW officer of the week to weekly meetings_ 
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The contents of Tables 26 through 28 can be reduced to the following five 
requirements: 

• Policies are needed to address issues of consistency throughout the 
enterprise 

• Policies must address issues of competition between organizations 

• Need to conduct an enterprise wide equal opportunity assessment 

• Publish a strategic plan for the enterprise to include the roles and 
responsibilities of organizations within the enterprise 

• Increase Public Affairs releases to increase awareness of 
achievements and reinforce the need for collaboration throughout 
the enterprise to achieve mission success 

Everyone in a leadership position should be acutely aware that perception is 
critical. Leaders must be aware of how they are perceived and ensure that the members 
of their command have the perceptions that the leadership wants to convey. Feedback to 
leadership is crucial for leaders to adjust perception as well as ensure that the leaders 
intentions are being accurately perceived throughout the organization. Perceptions can be 
reinforced or changed through policy and action. The Leadership Perception comments 
are listed in Tables 29 and 30. 


Table 29. Leadership Perception Data Points Part 1 


Leadership Perception Data Points 

The corporate culture focuses on individuals gaining power over others 

Individuals hoard information to make themselves seem more powerful 

Sharing is based on the 'good ole boy' system 

Individual biases 

Sometimes an ultimatum is necessary, even if others know the information is required 

Some individuals share only what is requested, despite knowing more is required 

Everyone trying to secure funding 

Individuals don’t see themselves as part of an enterprise 

Belief throughout the organization that sharing information may result in losing business to 
another organization 

Sharing information is helping your competition, which puts your job at risk 

Testers and range workers fear losing their jobs 

Lack of trust throughout the organization 

Individuals don't share in order to avoid being judged by their peers 

The belief that the info is mine so no one else can interpret it 

Individuals will use information in the central repository correctly if their interest is to help the guys 
overseas 

Share so everyone can benefit 
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Leadership Perception Data Points 

Individual's fear of data being misused _ 

Everything is done for the warfighters, and they are appreciative of it _ 

Everyone has emotional ties to making sure the warfighters are safe _ 

Protect the warfighter by ensuring that information is not taken out of context 
Organizational culture based on reaction to requirements from the war fighter means inherent 

flexibility _ 

Institutionalized financial resource competition between test ranges stops information sharing _ 

Bureaucracy has made the organization ineffective _ 

The reduced number of working groups results in less personal interaction _ 

Geographical distribution of JTB organizations challenges information sharing _ 

Managerial resistance to obtaining data from another organization _ 

JTB should provide cleaner roles for testing organizations _ 

Management intervention is often necessary to require others to share information _ 

Some individuals don’t know there is a necessity to share 
Decisions are made in a risk averse environment 

Organizational barriers exist between services _ 

Rivalries between sites and services create barriers _ 

Build trust with JIEDDO modeling and simulation _ 

The lack of a written Information Sharing policy results in confusion through reliance on a set of 
unwritten norms that individuals interpret differently 

Table 30. Leadership Perception Data Points Part 2 

Leadership Perception Data Points _ 

Protocols are open to interpretation _ 

People don’t know who to ask for what information _ 

Can’t figure out who to talk to for certain information _ 

Information received is not normally timely or accurate, which leads to getting the information through 

different means _ 

When sharing occurs, the amount of information received is inadequate _ 

Information required for budgeting is received quickly _ 

Access controls on who can post to the JTB portal increase trust in the posted information _ 

People get the information they need only after working through barriers 

There is a lack of access to information from other facilities and ranges _ 

There is a lack of access to documents that are known to be available to others _ 

Obtaining raw unfiltered data from a test range is a challenge _ 

People are reserved in large video teleconferences because they are not willing to share with information 

with all of the participants _ 

Some organizations attempt to repress certain information if it might be harmful to a system 

Much of the information gathered is proprietary and not shared _ 

Individuals don’t know who has what information _ 

Ealsely assuming that others have access to the same information _ 

Working group members don’t disseminate what they learn with co-workers _ 

Inability to locate documents that are known to exist in other organizations _ 

Processes do not have any policy or guidance to how they work _ 

End users have not heard of or about JTB, however most have heard of JIEDDO _ 

JTB interact with the end users either indirectly or not at all_ 
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The contents of Table 30 can be reduced to the following three requirements: 

• Leadership needs to address the perception of fear of consequences 
that might result in reprisals, job loss or loss of business for 
organizations 

• Leadership needs to address the perception of mistrust amongst the 
organizations within the enterprise and the lack of trust in 
management 

• Leadership needs to address the perception that there is a lack of 
concern from the top down 

B. BENEFITS OF MAKING THE CHANGES 

The JTB enterprise has grown into a complex organization. In order to maximize 
its capabilities the organization needs to implement changes to ensure information is 
reaching its intended audience. The JTB is spending millions of dollars of tax-payers’ 
money each year to mitigate the threat of lEDs. The implementation of a knowledge 
management program that coordinates knowledge sharing throughout the organization 
will ensure that efforts are being coordinated and redundancies eliminated ultimately 
saving money. The independent nature of each entity maintaining its own web hosting of 
information hidden behind unique passwords for each command inhibits collaboration 
across the enterprise. Access to information is essential if the knowledge is going to be 
used in theater. There needs to be a feedback mechanism to facilitate improvements to a 
system. Users of the knowledge gained through JTB testing need to have access, the 
ability to provide feedback and an easy accessible source of information on lEDs. 
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V. CONCLUSIONS 


Capitalizing on the data gathered from Gill (2011) and LaViolette (2011), the 
information was organized to identify specific subject areas that needed attention. By 
further refining the data into more specific sub-classifications it became easier to identify 
requirements for action to address identified issues. Developing requirements through 
data analysis allowed for an organization of ideas to produce lists of actions that could be 
assigned to people to effect positive change in the JTB enterprise. Issues of a similar 
nature were combined into comprehensive requirements to reduce the number of issues as 
well as to consolidate the issues into manageable tasks. Once requirements were defined, 
the issues can be addressed as specific tasks for assignment to personnel within the JTB 
enterprise to take advantage of the lessons learned from this research. 

A. ACTIONABLE ITEMS 

Change in an organization is never easy. People are resistant to change and do 
not readily accept that change will be for the good of themselves or the organization. The 
JTB requires a knowledge management program to ensure that the organization is 
operating efficiently. Budgets are continuing to be more of a challenge each year and 
only through a comprehensive knowledge of how the JTB is managing information, can 
managers make decisions on what processes are essential. The money that is spent to 
garner knowledge is not well spent if the knowledge gained is not accessible to those 
who need it. Further it is not apparent whether testing is being conducted that has 
already been done by the same lab or another lab. If the enterprise shared information 
more efficiently, the time to get information needed will go down and lives may be 
spared. There needs to be clear lines of communication throughout the JTB and there 
should be someone accountable for the communication systems for the whole enterprise. 

I. IT Requirements 

IT requirements have been classified as supporting the function of the system, 
nonfunctional requirements, or as constraints to the system. The only functional 
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requirement identified was that the data systems throughout the enterprise should be 
connected and interoperable. Nonfunctional requirements identified were to establish 
policies and procedures to ensure the system can be interoperable with other data systems 
throughout the organization. The nonfunctional requirements were identified as the need 
to create a standard operating procedure for information to get to and from a central data 
repository; the need to create a policy establishing standardized file formats; and the need 
to create policy for the format of data, the storage of data and the sharing of data. The 
only system constraint identified was the need to create multiple security level accesses 
to databases which would constrain the data accessibility of the system but ensure control 
of sensitive information. 

The assessment did identify specific requirements for changes to the JTB portal. 
The requirements identified were: 

• Create a single sign on for the JTB Portal and all websites within the JTB 
enterprise 

• Permissions to access web content should be managed by one point of 
contact 

• Create a customer feedback on the JTB portal 

• Create a link to a list of recently update documents on the JTB portal 

• Create a Frequently Asked Questions link to document common lED 
queries 

• Create a contact list by subject area for people to contact for more 
information on a subject area 

• The Request for Information process should require a point of contact for 
the request and then update the person requesting the information when 
there is a change to the RFI 

• Each website should have a point of contact for information contained on 
the web page 

• Add information Einks to websites outside of the enterprise 

In addition to data system requirements and changes to the JTB Portal the only 
other system requirement was identified as e-mail system related. Specifically the 
requirement to assign e-mail accounts to specific job functions or office codes to ensure 
correspondence was not lost when personnel have left their positions. 
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2. Policy Requirements 


Much like IT system requirements, policy requirements address the function of 
the system that is the organization. In order for people to function within the framework 
of the command policies the policies must be identified and implemented. The following 
policy requirements were identified: 

• Publish list of current policies and changes 

• Training is required to ensure members are cognizant of and understand 
command policies and changes to policies 

• Organization must have clear and defined authority over subordinate 
organizations 

• Sharing of information within the enterprise must be a standard that is 
enforced by command policy 

• Collaboration and networking must be encouraged through policies and 
practice 

• Policies are needed to address issues of consistency throughout the 
enterprise 

• Policies must address issues of competition between organizations 

• Develop a feedback process for adding or changing meetings and publish 
policy to the enterprise 

• Create policy on testing requirements 

• Create standard operating procedures for each department 

• Require the posting of weekly status reports to the portal 

In addition to having functional requirements of policy the data identified some 
confusion created by a perception of competition. While the issues were valid and need 
to be addressed they are considered nonfunctional requirements that need to be addressed 
to reinforce the command’s policy toward competition amongst the organizations 
supporting the JTB enterprise. The requirements identified were: 

• Clarify if competition is required amongst commands within the enterprise 

• Clarify what information is proprietary and what information is required to 
be shared within and outside the enterprise 

• Leadership needs to address the perception of fear of consequences that 
might result in reprisals, job loss or loss of business for organizations 
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• Leadership needs to address the perception of mistrust amongst the 
organizations within the enterprise and the lack of trust in management 

Management of organization policy was another area identified and the following 
requirements were identified: 

• Organization must have a position for Knowledge Manager/ Chief 
Information Officer to support effective knowledge sharing throughout the 
entire enterprise in accordance with the Army Knowledge Management 
regulations 

• Organization must have a position for Information Technology Manager/ 
Chief Technical Officer to create and enforce technology policies and 
procedures to ensure compliance with Department of Defense standards 

• Need to conduct an enterprise wide equal opportunity assessment 

• Leadership needs to address the perception that there is a lack of concern 
from the top down 

• Publish a strategic plan for the enterprise to include the roles and 
responsibilities of organizations within the enterprise 

• Mandate use of the JTB portal for collaboration 

• Increase Public Affairs releases to increase awareness of achievements 
and reinforce the need for collaboration throughout the enterprise to 
achieve mission success 

3. Process and Information Sharing Requirements 

Information sharing across the enterprise is critical to mission success. Specific 
requirements for sharing are not surprises but the lack of their presence has been a barrier 
to collaboration in the past. The identified information sharing requirements were: 

• Command organization, mission and strategy must be visible and 
accessible to all members of the enterprise 

• Knowledge must be managed throughout the enterprise and support the 
needs of the warfighter 

• Develop a map of data flow for processes throughout the enterprise 
architecture and within the research and development process and provide 
training on the processes 

• A comprehensive directory of personnel must be published and 
maintained for use of all personnel throughout the enterprise 

• Strengthen the teamwork concept by using the one team ethos 
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High turnover of personnel has resulted in additional barriers to collaboration. To 
mitigate the effects of turnover the following requirements were identified: 

• Process is needed to identify when personnel in key positions leave and 
document who will assume the responsibilities when a person does leave 

• Document position descriptions to identify positional responsibilities to 
lessen impact of personnel turnover 

Training was another area where information sharing could be improved by 
educating members of the enterprise. While training is always ongoing in any 
organization the following requirements were identified: 

• Training is required for members to understand the roles and 
responsibilities of the enterprise and the organizations within the 
enterprise 

• Training is required to clarify the process to account for changes to 
personnel in key positions and who to approach when a position is not 
filled. 

Sharing processes are often conducted through meetings whether they are in 
person, by telephone, by video teleconference or even electronic chat rooms. How 
meetings are conducted is important to the context of the meeting. The take away from 
the meetings however is the most critical to knowledge sharing. The key meeting 
requirements identified are: 

• Knowledge gained through meetings, testing or new directives should be 
published on a regular schedule to ensure the knowledge is shared 
throughout the enterprise 

• Document the current schedule of meetings within the enterprise, the 
purpose of each meeting, the format of each meeting (telecom, VTC, etc), 
state who should attend each meetings and publish the information to the 
enterprise 

• Document and share meeting agendas and meeting minutes to encourage 
knowledge sharing throughout the enterprise 

• Document what meetings take place with entities outside the enterprise 
and develop a feedback mechanism for entities outside the enterprise to 
provide customer feedback. 
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Requirements identified in this thesis were generated in the hope that they will 
support actions that will result in positive change to the JTB enterprise. The 
requirements listed are not intended to be comprehensive of all changes needed to 
address issues identified by the research. The goal of refining the issues into 
requirements was to make manageable tasks out of a large amount of qualitative data 
points. Initiatives in Knowledge Management go hand in hand with Data Management. 
Addressing issues with enterprise policies will likely resolve the majority of the issues 
identified. Aligning IT systems to be capable of collaboration will allow for the 
accessibility of data throughout the enterprise. The process of change management is 
continuous and the enterprise will need dedicated advocates to ensure consistent efforts in 
Knowledge Management and Data Management. The AKM Maturity Indicator (Table 1) 
identifies specific areas of evaluation of AKM principles that are necessary to have 
metrics on how well the enterprise is functioning. The AKM principles of 
People/Culture, Process and Technology are all elements that are constantly changing. 
As the personnel of the enterprise change, knowledge must be managed to ensure that 
there is no loss of knowledge when personnel leave. Additionally, new personnel will 
require training to assist them to learn lessons that other in the enterprise have already 
learned. To manage changes in the enterprise, leadership must be an advocate to the 
changes and ensure that policy and procedures are in place. Technology will continue to 
improve and the policies must account for changes to govern the systems. Use of new 
technologies like the JTB portal must have support of leadership to ensure personnel are 
capitalizing on the investment in technology. The JTB portal is perhaps the best 
collaboration tool available to the members of the JTB enterprise, yet is appears to be the 
least effective due to being unfriendly to users. 

Implementing change has to start with some basic steps to outline the objectives 
to be met through change and then the changes have to be championed by leadership. 
This thesis provides many requirements that would support positive changes in the JTB 
enterprise but to get started on those changes the strategic plan needs to be stated and 
disseminated throughout the enterprise. The strategic plan needs to contain an 
organizational chart and the plan needs to spell out how each component of the 
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organization supports the whole enterprise. To develop a strategic plan the key 
stakeholders in the enterprise need to meet to understand how the organizational structure 
currently functions and to adjust information flows as required by the leadership. 
Including the stakeholders in the development of the strategic plan gains the needed buy- 
in of stakeholders in the implementation of changes mandated by the strategic plan. The 
discussions that take place during the development of the strategic plan can also include 
how to integrate the knowledge management and data management changes. Once a 
formal strategic plan has been approved by leadership, a road show brief can be 
conducted at the many locations that comprise the enterprise. Leadership presence at the 
strategic plan briefs will reinforce the inclusion of smaller entities within the enterprise as 
well as provide an opportunity for the JTB enterprise members to see the leadership and 
express their concerns. Teamwork has strong roots in the members of the JTB enterprise 
and the members long to strengthen their teamwork with their counterparts throughout 
the enterprise. 

B. RECOMMENDATIONS FOR FUTURE RESEARCH 

This research has provided a summary of requirements that would support 
positive changes to the business processes at the JTB. JTB can utilize the requirements to 
implement Army KM best practices, as well as to develop standards of practice 
throughout its organization. This research does not represent a complete assessment of 
the organization. Follow on research could include an analysis of the budgeting process 
at the JTB. Further research could be conducted to quantify what specific knowledge is 
needed in theater and how to capture the experience learned in theater to assist the JTB. 
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